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Before JAMES T. MOORE, Vice Chief Administrative Patent Judge, and 
LEE E. BARRETT and LANCE LEONARD BARRY, Administrative 
Patent Judges. 

BARRETT, Administrative Patent Judge. 

DECISION ON APPEAL 

This is a decision on appeal under 35 U.S.C. § 134(a) from the final 
rejection of claims 1-5, 9, 14, 15, 17, and 18. Claims 6-8, 10-13, 16, 19, and 
20 have been canceled. We have jurisdiction pursuant to 35 U.S.C. § 6(b). 

We affirm-in-part. 



1 Filed December 29, 2000, titled "Apparatus and Method for 
Identifying a Requested Level of Service for a Transaction." The real party 
in interest is Hewlett-Packard Development Company, LP. 
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STATEMENT OF THE CASE 

The invention 

Appellants describe that prior art approaches to load balancing 
involve, for example, routing each new transaction to a new server (the 
round-robin approach) or directing transactions to the next available server. 
These approaches do no necessarily route transactions to the server that is 
best able to process the transaction. Spec. 2, 11. 4-19. 

The invention relates to computer readable program code stored in a 
computer readable storage medium for selecting a requested level of service 
for a transaction based on user input (independent claims 1, 5, and 9). The 
requested level of service can be any suitable factors. The transaction is 
disclosed as preferably a packetized signal comprising at least a data packet. 
A service tag is attached to the packet, where the service tag includes the 
requested level of service. See Abstract. 

The invention also relates to computer readable program code stored 
in a computer readable storage medium for selecting a requested level of 
service for a transaction and assigning a service tag to the transaction and 
directing the transaction over the network based on the requested level of 
service read from the service tag (independent claim 14). That is, the service 
tag is read from the transaction using suitable program code (e.g., at a load 
balancer), and based on the requested level of service, the transaction is 
directed to and processed by a network device that is best able to provide the 
requested level of service. See Abstract. 
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Illustrative claims 

Illustrative claims 1 and 14 are reproduced below: 

1 . An apparatus for identifying a requested level of service for a 
transaction, comprising: 

computer readable storage media; and 

computer readable program code stored in said storage media, 
comprising: 

a) program code for prompting a user to select a requested 
level of service for said transaction; and 

b) program code for assigning said requested level of 
service to said transaction. 

14. An apparatus for routing a transaction over a network based on 
a requested level of service associated with said transaction, 
comprising: 

a number of computer readable storage media; and 

computer readable program code stored in said number of 
storage media, comprising: 

a) program code for selecting said requested level of service 
for said transaction; 

b) program code for assigning a service tag to said 
transaction, said service tag including said requested level of 
service, and said program code assigning parts of said service 
tag at more than one point on said network; 

c) program code for reading said requested level of service 
from said service tag; and 

d) program code for directing said transaction over said 
network based on said requested level of service read from said 
service tag. 
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The references 

Davies US 6,483,805 Bl Nov. 19, 2002 

(filed Dec. 28, 1998) 
Bearden US 6,871,233 Bl Mar. 22, 2005 

(filed Jul. 5, 2000) 

The rejections 

Claims 1, 3-5, and 9 stand rejected under 35 U.S.C. § 102(e) as being 
anticipated by Bearden. 

Claims 14, 15, 17, and 18 stand rejected under 35 U.S.C. § 102(e) as 
being anticipated by Davies. 

Claim 2 stands rejected under 35 U.S.C. § 103(a) as unpatentable over 
Bearden and Davies. 

PRINCIPLES OF LAW 
"Anticipation requires the presence in a single prior art disclosure of 
all elements of a claimed invention arranged as in the claim." Connell v. 
Sears, Roebuck & Co., 722 F.2d 1542, 1548 (Fed. Cir. 1983). 

FINDINGS OF FACT 

Bearden 

Bearden describes a "framework that enables a system administrator 
to specify service-level quality of service (QoS) goals for automatic 
enforcement." Abstract. 

As shown in Figure 1, QoS goals are represented using a generalized 
goal template. Col. 2, 11. 43-45. 
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Davies 

The background of Davies describes that packet switched networks 
achieve very high speeds by keeping the amount of interpretation at each 
packet at a node to a minimum. In general, two decisions need to be made: 
which output link the packet is to be directed to; and what treatment (e.g., 
prioritization) it should be given within the node. Col. 1, 11. 14-20. 

Typically the output decision is made solely on the basis of the 
destination address. Treatments within a node are restricted to two classes 
of prioritization. Network control traffic is typically given absolute priority. 
All user traffic (the remainder) is treated identically. Col. 1, 11. 21-36. 

Davies describes that the Destination Address field and, optionally, 
the Type of Service (ToS) field are used as indices into a forwarding table 
constructed by means of the dynamic routing protocols to find the correct 
output link for the packet. Col. 1, 11. 44-47. "Routing responsive to the 
contents of the ToS field is currently extremely uncommon although it has in 
principal been available since the early definition of IP." Col. 1, 11. 47-50. 

The invention in Davies is designed to operate in the context of a 
Differentiated Service (DS) architecture which provides a framework for 
implementing additional services with enhanced QoS. Col. 6, 11. 37-40. The 
DS architecture has DS Edge Devices at the ingress and egress nodes and 
DS Interior Devices at the interior nodes. Col. 6, 11. 56-62. 
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Davies describes the DS architecture as follows: 

Both DS Edge and DS Interior Device in a given DS Domain 
must implement a consistent set of forwarding treatments which are 
knows as Per Hop Behaviors (PHBs). The DS architecture supports 
enhanced Quality of Service (QoS) for Internet Protocol (IP) services 
by means of marking each individual packet used to deliver data 
across an IP network with a code comprising a small number of bits. 

Every traffic aggregate which passes through a DS node is 
marked with a DS codepoint (6 bit number) which indicates the class 
of traffic. The codepoint is used (for example using a mapping table) 
to select the PHB to which the traffic is subjected as it passes through 
a node. 

Col. 6, 1. 63 to col. 7, 1. 8. 

The nodes "ensure that traffic aggregates are correctly marked and are 
within any contract (Service Level Agreement) which a customer of the DS 
Domain may make with the domain owner." Col. 7, 11. 10-13. "The traffic 
conditioning will normally involve admission control mechanisms which 
can dynamically admit or reject portions of the traffic aggregate to ensure 
that the SLA is not contravened." Col. 7, 11. 13-16. 

Prior art packet-by-packet admission control focused metering the rate 
of flow associated with an aggregate and either discarding packets which are 
in excess of the agreed rate or offering inferior services by altering their 
codepoints. Col. 7, 11. 20-24. Such mechanism is said to be unsuited for 
transactional flows where the concept of an agreed flow rate is not relevant. 
Col. 7, 11. 25-29. Transactional service is characterized by a time-limited 
data chunk. Col. 7, 11. 53-59. 
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The invention in Davies is directed to an end-to-end flow control 
mechanism for transactional applications where the initial packet is marked 
with a specific class A, the last packet is marked with class C, and the 
intermediate packets are marked with B. By counting the number of packets 
marked with first and last class codes, the network management system can 
estimate the approximate load on the network by a transactional service and 
can use this information to deny admission to new requests. Cols. 8-10. 

DISCUSSION 

Claims 1 and 4 

The issue in dispute is whether Bearden describes "a) program code 
for prompting a user to select a requested level of service for said 
transaction" as recited in claim 1 . 

Appellants argue that Bearden describes setting Quality of Service 
(QoS) goals for all transactions, not for any particular transaction. Br. 10. 

The Examiner responds that "if the client is only prompted to specify 
a QoS goal for all transactions in Bearden's as stated by Appellant, 
'prompting a user to select a requested level of service for said transaction' is 
implied as well." Ans. 11. 

We agree with the Examiner that selecting a QoS level for all 
transactions or all data as in Bearden includes specifying a QoS level for a 
transaction as recited in claim 1. Claim 1 only requires selecting a level of 
service for a transaction and does not say how the level of service is 
implemented; e.g., claim 1 does not recite that the requested level of service 
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is embodied in a service tag associated with a data packet as recited in 
claim 2. Claim 1 also does not specify how the level of service is to be used; 
i.e., it does not recite that the level of service will be used to direct the 
transaction as recited in claim 14. Appellant has not shown error in the 
Examiner's rejection. The rejection of claims 1 and 4 is affirmed. 

Claim 3 

The issue is whether Bearden describes "program code for selecting a 
backup level of service" as recited in claim 3. 

Appellants argue that the portion of Bearden relied upon by the 
Examiner, Figure 4 and column 5, line 45 to column 6, line 24 only refers to 
allocating and deallocating network resources to achieve a single QoS goal 
and not a "backup level of service." Br. 10. 

The Examiner responds: 

Column 6, lines 1-7, Bearden discloses determining and 
executing a set of actions to reduce network resources if the delivered 
QoS exceeds the selected QoS, inherently saving or keeping the 
exceeded amount of the QoS in a safe place, (i.e. Examiner construed 
this limitation as 'backup level of service' or backup (i.e. to make a 
copy of important data onto a different storage medium for safety . . . 
since they have the same functionality)." 

Ans. 11. 

Appellants argue that the Examiner errs in interpreting a "backup 
level of service" to be a backup or copy instead of a level of service if the 
selected level of service is not available. Reply Br. 3-4. 
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We agree with Appellants that a "backup level of service" cannot 
reasonably be interpreted to be a backup in the sense of a copy as stated by 
the Examiner. A "backup level of service" is a level of service if the 
selected level of service is not available. We also do not agree with the 
Examiner's statement that reducing network resources implies storing the 
exceeded amount of QoS in a safe place. QoS refers to an ongoing measure 
of service, not data that can be stored. 

The limitation of "program code for selecting a backup level of 
service" in claim 3 does not require allowing a user to select a backup level 
of service, but could refer to the program code selecting a backup or default 
level of service. Nevertheless, the Examiner has not pointed out how any 
program code "selects" a backup level of service. Accordingly, the rejection 
of claim 3 is reversed. 

Claim 5 

Appellants make essentially the same argument for independent 
claim 5 as for claim 1. Therefore, the rejection of claim 5 is affirmed for the 
reasons stated for claim 1 . 

Claim 9 

Appellants argue that claim 9 should be allowable for reasons similar 
to claim 1. Since we affirm the rejection of claim 1, we also affirm the 
rejection of claim 9. 
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Claims 14, 15, 17, and 19 

1. 

The first issue is whether Davies describes "a) program code for 
selecting said requested level of service for said transaction" in claim 14. 

The Examiner refers to column 7, lines 47-59. Final Rej. 5. 
Appellants argue that they fail to appreciate the relevance of this portion of 
Davies and this portion of Davies teaches away because it states that it is 
"difficult to create" a single class of packet for a transaction. Br. 13-14. In 
response, the Examiner refers to column 6, line 63 to column 7, line 8, and 
finds that the codepoint selecting the Per Hop Behavior (PHB) is 
"inherently" the same as selecting the requested level of service. Ans. 12. 
Appellants argue that inherency is inappropriate since there is no teaching 
that it must necessarily be so. Reply Br. 5. Moreover, it is argued that 
Davies routes packets, as opposed to transactions. Id. 

Limitation "a)" does not require that a user select the requested level 
of service. Davies describes that QoS is supported by marking packets with 
codepoints that indicate a class of service which is used to select a PHB. 
Col. 6, 1. 63 to col. 7, 1. 8. We find that the class of service in the codepoint 
teaches a "requested level of service." The Examiner's statement that the 
PHB is "inherently" the same as a requested level of service in an 
unfortunate choice of wording, but Appellants have not shown that the 
codepoints do not represent a level of service. As of this point in claim 14, 
the use of the level of service has not been claimed. 
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The description at column 6, line 63 to column 7, line 8 of Davies 
does not exclude the packets representing "transactions." That is, a specified 
QoS applies to all data transmitted as packets, and since transactions are 
carried by packets in both Davies and the instant invention, the QoS is 
applied to transactions. As noted in the analysis of claim 1, we agree with 
the Examiner that a QoS level for all data includes a QoS level for all 
transactions in that data including a particular transaction. Although Davies 
describes that it is difficult to create a Service Level Agreement (SLA) for a 
single class for packets because the network is unable to predict or readily 
control the load imposed by this traffic (col. 7, 11. 47-52), this does not 
negate the codepoint teachings at columns 6 to 7. 

Therefore, we find that Davies teaches "a) program code for selecting 
said requested level of service for said transaction." 

2. 

The second issue is whether Davies describes "b) program code for 
assigning a service tag to said transaction, said service tag including said 
requested level of service, and said program code assigning parts of said 
service tag at more than one point on said network," as recited in claim 14. 

The Examiner refers to column 6, line 66 to column 7, line 6 and 
column 8, line 62 to column 9, line 4. Final Rej. 5. Appellants argue that 
columns 6-7 of Davies describe marking individual packets , whereas 
claim 14 recites assigning a service tag to a transaction . It is argued that 
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columns 8-9 are not relevant to the claimed limitation. Br. 14. The 
Examiner responds by describing the teaching of columns 6-7. Ans. 12. 

As noted supra, we find that the codepoints in Davies correspond to a 
level of service. The codepoints attached to packets correspond to service 
tags. Also, we find that the packets in Davies include packets that carry 
transactions and therefore, assigning a codepoint to a packet includes 
assigning a service tag to a transaction. 

Therefore, we find that Davies teaches "b) program code for assigning 
a service tag to said transaction, said service tag including said requested 
level of service." 

3. 

The third issue is whether Davies describes "c) program code for 
reading said requested level of service from said service tag; and d) program 
code for directing said transaction over said network based on said requested 
level of service read from said service tag." 

The Examiner refers to column 7, lines 34-45. Final Rej. 5. 
Appellants argue that Davies routes packets , not transactions . Br. 15. It is 
also argued that the bits determine classes which are then subject to class- 
specific routing, where routing is passive execution of processes to allow a 
packet to reach its intended destination, whereas "directing" in claim 14 
actively determines where the transaction is to go. Id. The Examiner 
responds that a router directs packets. Ans. 13-14. 
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Appellants have not established that the stream of codepoint-labeled 
packets in Davies do not contain transactions. 

The problem we see is reading the limitation of "directing said 
transaction over said network based on said requested level of service read 
from said service tag" onto using the codepoints of Davies. The first part of 
the limitation, "directing said transaction over said network," does not 
require a specific end destination, such as a specific server out of several 
servers that can provide the best service, and reads on the normal routing 
function of a network router using the packet destination address. However, 
the second part of the limitation, "based on said requested level of service 
read from said service tag," requires that the routing be based on the level of 
service. It is not apparent that Davies performs any routing over the network 
based on the class contained in the codepoint, nor does the rejection appear 
to address this specific limitation. The codepoint is used to select the PHB 
(col. 7, 11. 4-8), but the PHB is not described and is not specified to be a 
route. Davies describes that "[t]he codepoint is used ... to select the PHB to 
which the traffic is subjected as it passes through a node" (col. 6, 11. 6-8), 
which indicates the PHB relates only to "treatment" within the node (e.g., 
prioritization) as opposed to routing. As far as we can determine, the routing 
of packets is based on the Destination Address field (col. 1, 11. 44-47), not 
the codepoint. While there is some suggestion that routing could be 
performed based on the Type of Service (ToS) field in the packet header 
(col. 1, 11. 47-50), the Examiner does not rely on this teaching, nor has it 
been shown that a ToS is a level of service. 
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Because Appellants have shown error in the Examiner's finding that 
Davies teaches "d) program code for directing said transaction over said 
network based on said requested level of service read from said service tag," 
the anticipation rejection of claims 14, 15, 17, and 18 is reversed. 

Claim 2 

Claim 2 is rejected for obviousness over Bearden and Davies. The 
Examiner concludes that Bearden does not teach associating a service tag 
indicating a level of service with a data packet representing a transaction. 
The Examiner finds that Davies teaches codepoint tags attached to packets to 
indicate a QoS. The Examiner concludes that it would have been obvious to 
modify Bearden to provide service tags on packets indicating the QoS in 
view of Davies. Final Rej. 7-8. 

Appellants argue that the references lack any suggestion to be 
combined and that such a combination would be counterintuitive. It is 
argued that Davies teaches routing of packets and Davies views the problem 
of managing individual flows of packets, let alone the individual packets, as 
an impossibility. Br. 16. 

Davies teaches marking individual packets with a code indicating a 
class of traffic for QoS purposes. We agree with the Examiner that one of 
ordinary skill in the art would have been motivated to implement the QoS 
selections in Bearden using codes attached to individual packets in view of 
Davies because Bearden does not teach how the QoS will be implemented 
and Davies teaches that codes were a known way to indicate level of service 
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for packets. As with claim 1, our reasoning is based on the interpretation 
that selecting a QoS level for all data in Bearden includes specifying a QoS 
level for all transactions. While Davies states that QoS cannot be specified 
at the granularity of individual levels of flow, claims 1 and 2 are not limited 
to specifying a level of service of an individual transaction. Appellants have 
not shown error in the Examiner's rejection. The rejection of claim 2 is 
affirmed. 

CONCLUSION 

The rejections of claims 1, 4, 5, 9, 14, 15, 17, and 18 under 35 U.S.C. 
§ 102(e) are affirmed . The rejection of claim 3 under 35 U.S.C. § 102(e) is 
reversed . 

The rejection of claim 2 under 35 U.S.C. § 103(a) is affirmed . 
Requests for extensions of time are governed by 37 C.F.R. § 1.136(b). 
See 37 C.F.R. § 41.50(f). 

AFFIRMED-IN-PART 
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